<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Backporting complete',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/08/07.jpg" alt="The other construction site" class="framed-centred-image" width="649" height="480"/>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion posts for the day:
	</p>
	<blockquote>
		<p>
			I agree that people need hope to carry on.
			However, I don&apos;t agree that people need a god to be the source of their hope.
		</p>
		<p>
			I had a run-in with a cult not too long ago.
			I didn&apos;t realise they were a cult at the time, but they said a lot of things that made sense.
			As well as several things that didn&apos;t.
			Still, they had me questioning whether their gods were real.
			(They believe in two: a mother god and a father god.)
			The closer I came to believing, the closer I came to despair.
		</p>
		<p>
			It was a Christian-based cult, so many of the base ideas were decidedly Christian, such as that we can only be saved by believing in Jesus.
			However, several things specific to this cult explained Christianity&apos;s quirks far better than I&apos;ve ever heard before.
			For example, they said we lived in heaven, but we didn&apos;t know our place.
			We got prideful and thought we were important, which Yahweh (the Christian god, the father god in this variant of Christianity) had proclaimed to be a crime punishable by death.
			We were put on this planet, a prison planet, to be given a second chance.
			If we showed we could learn our place and submit, we could go back to heaven.
			It explains perfectly why people that don&apos;t believe in Jesus supposedly don&apos;t get saved, even if they&apos;re the best people in the world.
			If we show that we know ourselves to be inferior to and at the mercy of Jesus (who this cult believed not to be the son of Yahweh, but the incarnation of him), we will have shown that we&apos;re no longer committing the &quot;crime&quot; of not knowing our place and thinking we actually matter.
		</p>
		<p>
			As I considered the possibility more and more, I found myself hurting more and more as well.
			I&apos;ve already accepted that my earthly parents don&apos;t care much about me.
			My mother can&apos;t even accept my gender.
			But at least she wouldn&apos;t throw me away just for believing I matter.
			Believing that there might exist a pair of gods that created me and wanted me to live in subjugation and with an inferiority complex was a source of growing pain.
			Before researching and deciding whether I believed or not, I needed to know what my stance would be if I <strong>*did*</strong> believe.
			Would I bow down to these abusive, power freak of gods so as to save my soul, even though they clearly were not worthy of <strong>*anyone&apos;s*</strong> praise or admiration?
			Or would I do the right thing and tell these gods to stick it, knowing it&apos;d likely land me in either hell or oblivion?
		</p>
		<p>
			Thankfully, on a whim, I decided to search for a term given to me by the cult, and it brought up info on the cult, including the fact that they are a cult, which until this point, I hadn&apos;t realised.
			It turns out they have a big money-making scam going on behind the scenes, too.
			They may have made sense, but it&apos;s highly unlikely they&apos;re actually led by any deities.
			I hadn&apos;t yet made my decision as to what to if I believed, but it was no longer relevant.
			my torment was over.
		</p>
		<p>
			Having a god or gods doesn&apos;t necessarily result in hope.
			It can be just the opposite.
			I&apos;ve yet to see any version of a god from any religion that is actually benevolent.
			They&apos;re all either outright malicious (see all versions of Christianity that I&apos;ve ever run across) or they have their own agenda and don&apos;t act on behalf of mankind (see many other religions, especially old ones such as the Greek and Norse religions).
			Even the ones with their own agenda may be malicious at times (especially the Greek gods), but they&apos;re usually not focused on us lowly humans, so we&apos;re kind of safe from them (I mean, if they&apos;re even real).
		</p>
		<p>
			Yahweh also isn&apos;t a source of morality.
			He&apos;s a source of act-as-I-say-or-I-punish-you.
			Behaving out of fear isn&apos;t true morality.
			Even if it was, there are plenty of us atheists that have very strong senses of morality.
			Believing in a god isn&apos;t required for developing morality, and I&apos;d even say religion is often times detrimental to finding morality.
			The only people that ever seem to tell me off for being queer for example, even though I don&apos;t choose to be queer, are the highly religious.
			I mean, not all religious people hate me for being queer.
			I&apos;m not saying that.
			But all people that hate me for being queer are religious and do so because of their religion.
			Hating someone for being themself in a way that doesn&apos;t harm anyone isn&apos;t exactly a moral thing to do.
			Religious wars aren&apos;t exactly moral either.
		</p>
	</blockquote>
	<blockquote>
		<p>
			I can see why believing that everyone&apos;s good at the core would be inspiring.
			I guess I&apos;m too jaded to believe everyone&apos;s actually good though.
			I&apos;ve seen too many bad people.
			They could be good at the core, corrupted by situation.
			There are just too many bad people for me to believe that though.
			From what I can tell, most people tend to be naturally very selfish and uncaring.
			It takes actual effort to care about others, and most people don&apos;t seem to want to put in the effort.
		</p>
		<p>
			You make a good point about shame though.
			Perhaps it&apos;s the good in people, regretting the bad that has been allowed to take over.
			Then again though, maybe shame is just a result of people&apos;s actions being exposed when they wanted them to remain secret.
			People naturally care what others think, so they try to maintain appearances.
			When those appearances are shattered, perhaps that&apos;s the source of shame.
		</p>
	</blockquote>
</section>
<section id="Minetest">
	<img src="/img/CC_BY-SA_3.0/minetest.net./weblog/2018/08/07.jpg" alt="The view when I first spawned in my new world" class="framed-centred-image" width="800" height="600"/>
	<h2>Minetest</h2>
	<p>
		I went looking through the Minetest $a[API] documentation for version 0.4.0 to see what I could use to implement mod storage.
		It seems there&apos;s only one thing.
		I think modern mod storage basically uses $a[JSON], but it&apos;s abstracted away so modders don&apos;t have to deal with it.
		Because it&apos;s abstracted away, I don&apos;t need my back end to actually be in $a[JSON] in Minetest 0.4.0 doesn&apos;t know how to parse $a[JSON].
		And predictably, it seems it doesn&apos;t.
		$a[JSON]-parsing was added to the engine separately from mod storage, but it&apos;s still fairly new.
		I also looked for the settings file parser.
		That&apos;s also missing.
		Come to think of it, I&apos;d been excited when that feature was added, so it wasn&apos;t before my time like the version of the Minetest engine I&apos;m working with is.
		I was excited because I planed to use it as a data-storage mechanism, exactly like I planned to do today.
		No, the one thing that exists in this version that seems like it&apos;ll work is the old <code>minetest.serialize()</code> function.
		That thing would be completely useless without a way to write to and read from files, so I knew writing to and reading from files must be supported already.
		I just needed to figure out the right function for that, which I thought I recalled isn&apos;t in the Minetest-specific $a[API], but in the main Lua language.
	</p>
	<p>
		I got a dummy version of storage put together that doesn&apos;t actually save anything, and found several other new method calls that don&apos;t work in legacy Minetest.
		I had to implement those too.
		Several of these methods were implemented as dummies because their only usage was in updating legacy <code>minestats</code> databases, but several had to be actually implemented with good code.
		And when I got everything working, I found the ancient Minetest Game copy spawned a world of void.
		I needed to update to a slightly-newer version of the game.
		After some more crash-fixing, My only real complaint is that without the <code>minetest.get_all_craft_recipes()</code> method from the modern $a[API], there doesn&apos;t seem to be a way to distinguish bricks and clay lumps from other drops so they can be eliminated from the counts automatically.
		I did add some hacky hard-coded stuff to keep them out of my way though.
		If any of this were production code, it&apos;d be unacceptable.
		I think it works decently well though, given that it&apos;s just a shim to get modern <code>minestats</code> running on the legacy engine.
		Even the updated unstable Minetest Game seemed to be broken, so I upgraded to the stable 0.4.0 game.
		You can&apos;t see where you&apos;re digging in the unstable game I&apos;d been using, for example.
		Even the stable version is broken in creative mode, but I don&apos;t plan to use creative mode for much of my testing anyway.
	</p>
	<p>
		My next step was to replace my dummied-out mod storage with something that actually stores data.
		It didn&apos;t yet save the data, but it&apos;d store it within the span of a single play session.
		However, <code>minestats</code> still wasn&apos;t counting anything.
		I looked into the old Minetest code and found the <code>minetest.handle_node_drops()</code> method wasn&apos;t yet in place.
		What <code>minestats</code> does wouldn&apos;t be possible without that method without copying part of the engine&apos;s code into <code>minestats</code>.
		So I copied the necessary code into my shim and made the necessary changes.
		<code>minestats</code> still wasn&apos;t counting though.
		I tracked down the problem, and it seems a backwards-incompatible change was made to Minetest in the past.
		<code>minetest.get_node_drops()</code> used to take a node name, but in modern Minetest, it takes a table of three node values.
		With a fix for that in place, <code>minestats</code> was finally actually counting drops.
		From there, getting drop counts to remain persistent between sessions didn&apos;t take a whole lot of effort.
	</p>
	<p>
		With the <code>minestats</code>-related part of my task complete, I stopped to run my Tuesday errands.
		I couldn&apos;t help[ but plan for my work on <code>alchemic_classic</code>, and as I did so, I realised I&apos;d run into two strange corner cases later on in the alchemy project.
		Both of them affected cotton and only cotton.
		Well, one technically also affects string, a cotton-based item.
		Anyway, the first issue is that of palettes.
		When cotton was introduced, palettes hadn&apos;t yet been added to the engine.
		Under my then-current stipulations, that meant I couldn&apos;t use palettes for the bulk of my cotton-based recipes.
		Yet at the same time, those are the only recipes I have reason to use the palette feature with at all.
		I decided to make an exception to the only-legacy-features rule for palettes.
		I tried to rationalise it, but there&apos;s really no logical reason why this exception should be valid.
		Still, I&apos;m doing it anyway.
		It&apos;ll be a huge mess if I don&apos;t.
		Second, I have the issue that string was repurposed.
		First, there was string.
		Then it got replaced by cotton.
		In an upcoming version of the game, string will be reintroduced with a new function.
		By then-current stipulations, that meant I should have string take on its original purpose in alchemic recipes.
		Of course, when cotton was introduced, as it replaced string, it had the same purpose as string.
		By then-current stipulations, that pretty much meant string and cotton would serve the same purpose in alchemic recipes.
		Cotton-based recipes are so much of a niche though.
		There really is no good way to do that same task twice.
		I&apos;ve decided that in the event that one element replaces another, which only happened so far this once, I&apos;ll work as though the role had always been given to the replacement element.
		If I know the old element&apos;s item to be brought back in a later version (which again, has only happened this once), I&apos;ll treat the new purpose of that item as the element&apos;s original purpose.
		Honestly, I think this exception is the best way to keep the results of my work consistent.
	</p>
	<p>
		Back on task, I started trying to backport <code>alchemy</code>.
		That didn&apos;t &apos;go well.
		It seems older versions of the Minetest engine didn&apos;t have the option of handling field values sent from inventory formspecs.
		Alchemic crafting could not be added to the inventory menu.
		It wouldn&apos;t be possible to even try until Minetest 0.4.2.
		At first, I thought I had two choices.
		I could either upgrade to version 0.4.2, in which case I risk tainting the conception of the classic alchemic recipes, or I could create an &quot;alchemy workbench&quot; node at which to perform feats of alchemy.
		I&apos;m not even sure nodes can handle the task this early in Minetest&apos;s history, so that might not even work.
		Still, I thought trying the workbench node was the better option for the development of the early alchemic recipes.
		Sticking to this early version of Minetest keeps my options limited, and thus the results simple.
		More-complex alchemy results can be added later, using newer elements.
		I think by the time mese crystals are introduced, which will be the next stop on my trek through Minetest history, I&apos;ll have what I need to put alchemy into the main crafting menu.
	</p>
	<p>
		Later though, I realised that none of the ancient elements can be combined using normal recipes, meaning that I could define the alchemic recipes as regular recipes for the time being.
		That completely eliminated the need to get <code>minestats</code> running on legacy Minetest, but unfortunately, I&apos;d already put in the time to do just that.
		As a bonus, this method will actually make testing easier.
		I won&apos;t have to worry about mining four stacks of every element to test each of the new items.
	</p>
</section>
END
);
